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I. INTRODUCTION 



Advances in integrated circuit and microprocessor 
technology have allowed increasingly diverse applications of 
these devices. The decrease in their size and power 
requirements and the increased market for them has resulted 
in a decrease in costs while yielding increased computing 
power. If this trend continues, an even broader variety of 
applications can be expected. The effects of increased 
complexity and the decrease in component costs will lower 
total hardware costs. However, as shown by Shooman [Ref. 1] , 
software costs can be expected to remain high for three 
reasons: new applications will require new programs to be 

written, the replacement of older, existing computers with 
newer versions will require either completely new software 
or, at the very least, modifications to existing software, 
and because programming is highly labor intensive, it will 
be strongly affected by inflation. In fiscal year 1980, 
fifty-seven billion dollars were spent on computer systems. 

Of this amount, thirty-two billion dollars, or fifty-six 
percent, was allocated to software [Ref. 2], It can be 
concluded that the most costly expenditures associated with 
computer system development and/or modification are software 
related, and this situation can be expected to remain 
unchanged. It is therefore to our advantage to automate 
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software production. The effort, in terms of manpower, 
required to develop a given software implementation, as well 
as the monetary expense necessary to support it, can then be 
devoted to the research and development of new systems and 
applications . 

The application of digital computers to the problems of 
real time control is an increasingly important aspect of 
computer technology, and is representative of the uses which 
can be expected with technological advances. The design of 
such systems has proven to be a complex and expensive 
undertaking. The concepts which will reduce this complexity 
and a methodology for the automated production of real time 
control systems have been developed. [Ref. 3] While no 
computer exists which can duplicate the creative process of 
design illustrated in Figure 1, there are elements of it 
which can be tasked to the computer for accomplishment. In 
order to determine what portions of the design process can 
be automated, the methodology used by the designer must be 
studied. The steps he follows usually involve combining 
existing elements or components in such a way that the 
desired system is realized. The components that are used are 
selected from a library of such items which is located 
either in the designer's memory or is contained in a 
physical listing. Because the components contained in the 
listing are regularly ordered, a computer can be used to 
maintain it, and, when given the specifications of a desired 
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Figure 1. The Design Process 
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system, it can select the necessary entries. This portion of 
the design process has been successfully automated [Ref. 4] 
and is illustrated in Figure 2. The proposed design tool 
merges the ideas of automated software generation and 
automated hardware production into one system. The 
description of this system is the subject of chapter two. 

The original intent of the design tool was to automate 
the production of the software and hardware necessary for 
the realization of real time controllers, but if this tool 
is to be a truly useful design aid, it must be applicable to 
a wider variety of problems. The implementation of digital 
filters is suitable for a dedicated microprocessor system, 
and is typical of potential applications problems. 

Digital filtering has been the subject of considerable 
research during the past fifteen years. Various implemen- 
tations have been achieved, including hardwired logic, 
special-purpose computers, and general-purpose computers. 

With the development of the microprocessor, and the recent 
increases in wordsize and speed, a new alternative is 
available. The application of the proposed design system 
to the implementation of microprocessor-based digital 
filters is the subject of this thesis. 

The difference equation form of the filtering function is 
well-suited to microprocessor realization. However, the 
algorithm used can be expressed in a variety of ways. 

Chapter three discusses four possible implementations. The 
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Figure 2. Automated Hardware and Software Generation 
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mathematical descriptions discussed are chosen for their 
simplicity and ease of implementation, but should not be 
construed as the only available alternatives. The 
possibilities are virtually unlimited. The filtering 
function can be performed using one of two general methods, 
independent of the algorithm chosen. The first method 
defines the transfer function as the product of the first and 
second order sections. This is the familiar cascade form of 
the digital filter. The alternative method is the parallel 
form, which expresses the transfer function as the sum of 
first and second order sections. [Ref. 5] The methods for the 
general implementation of each of these applications within 
the bounds of the design system are also discussed in chapter 
three. The optimization of the solution is not of concern. 

The best realization, as determined by metrics such as memory 
use and chip count, is not the current objective of the design 
system. If the implementation produced satisfies the 
requirements of the problem in terms of timing constraints 
and function, the solution is acceptable. 

The application of the design system to problems other 
than controller design is important for several reasons. By 
demonstrating the ability of the system to generate success- 
ful realizations for a wide variety of problems, its overall 
utility as a design tool will be proven. Varying the type 
of implementation problem presented to the system extends 
the applicability of the design technique and refines our 
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understanding of the system. By testing various applications, 
inadequacies in the current implementation of the system can 
be detected and corrected. The attempt to generate digital 
filters using the design system revealed a number of such 
problems and the search for these inconsistencies became a 
major portion of the thesis. The problems found are presented 
with corresponding solutions in chapter four. 

Chapter five describes the application of the design 
system to realistic problems. The concepts discussed in the 
previous chapters are utilized to implement both the cascade 
and parallel forms of a fourth order digital filter. 

The system described in this thesis represents a useable 
design tool. Unfortunately, the coding that the user is 
required to produce in order to achieve the desired hardware 
and software realization is both awkward to use and tedious 
to generate. The addition of new realization volumes, as 
well as the maintenance of existing ones, is a difficult 
process as well. The potential of the design system is 
therefore limited by our ability to simplify the user input 
specification and provide a means by which the software and 
hardware library may be modified to accommodate any potential 
design problem. Recommendations for these and other 
improvements are contained in the sixth and final chapter. 
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II. SYSTEM OVERVIEW 



The current version of the design system has evolved 
from the model proposed by Matelan [Ref. 6] and implemented 
by Ross [Ref. 7], Each of these efforts used the design of 
real time controllers as the problem model for development 
of the system. The concepts and terminology introduced by 
Matelan can be found in the current implementation. The 
results of this work are summarized here. 

A. PROBLEM MODEL 

The first aspect of the system to be considered is the 
problem model. In order to produce a successful realization 
for any problem, it must first be expressed in a form 
understandable by the design system. 

1 . Contingency/Task Pairs 

Each problem can be expressed as a collection of 
contingency/ task pairs, where a contingency is defined as a 
logical or relational function of some input variable or 
variables. The associated task is executed when the 
contingency is satisfied. Therefore, the first step in 
developing a realization is to express the problem in terms 
of contingency/task pairs. 



17 



2 . High Level Problem Description 

Implicit in the model of the problem are rigid 
constraints on the testing of each contingency and the time 
allowed for execution of the corresponding task. The 
designer must specify these real time requirements in the 
statement of the problem. Matelan proposed a new high level 
design language called a Control System Design Language, or 
CSDL, for this purpose. The language consists of four 
sections: identification section, environment section, 

contingency list, and procedures section. The identification 
section is a record of the user identification of the 
problem. The environment section specifies the interface 
between the device and the process which is to be operated 
upon. It defines all input and output variables and their 
characteristics, as well as those variables internal to the 
mathematical operation of the device. The contingency list 
is a declaration of those conditions that the device must 
respond to, the associated task that each must execute, and 
the real time constraints imposed upon each pair. The timing 
constraints are determined by the maximum time allowed to 
recognize a contingency and the maximum time available to 
execute the corresponding task. The routines which comprise 
each contingency/task are contained in the procedures 
section. By definition, contingencies are written as 
functions, while tasks are specified as procedures. Each 
contains the high level descriptions necessary for the 
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performance of its role in the system being produced. Figure 
3 is an example CSDL listing of a simple filtering problem. 

The identification section is readily found and easily 
understood. The environment section specifies two variables, 
one for input and one for output. Each contains eight 
TTL-compat ible bits. The contingency section indicates that 
the function READY is executed every millisecond, and when 
true, the task FILTER is performed. The procedures section 
contains the descriptions of the steps necessary to perform 
the test for the contingency READY and the execution of the 
process FILTER. In the case of the contingency READY, an 
external variable, DATA, is read. If its value is one, 
indicating the presence of data for processing, the 
contingency is satisfied and the value of READY is set to 
one, and the task FILTER is executed. If, on the other hand, 
DATA is equal to zero, the contingency will not be satisfied 
and READY will remain equal to zero to indicate a false 
condition. The task FILTER is not executed under these 
circumstances . 

The function FILTER contains the description of the 
difference equation 

y(n) = x(n) + 0.5y(n-l) - 0.5y(n-2). 

The value of the input is assumed to be in digital form and 
is read first. The value of the corresponding filtered 
output is then computed and the result is issued as an output. 
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IDENTIFICATION: 

DESIGNER: M. R. H e i 1 s t e d t 

DATE: 19 Aori 1 1983 

PROJECT: CSDL ExamDle - Filter 

ENVIRONMENT: 

INPUT: X,8,TTL 
OUTPUT: Y, 8, TTL 

CONTINGENCY LIST: 

When READY : 1 MS Do FILTER 

PROCEDURES : 

Contingency READY 
Sense (DAT A ) ; 

If DAT A= 1 Then RE ADY : = 1 fi; 
Exit READY 

Task FILTER 

Sense ( X ) ; 

Y=X+(0.5*YN1)-(0.5*YN2); 
Issue ( Y ) ; 

YN2=YN1 ; 

YN 1 =Y ; 

Exit FILTER 



Figure 3. Example CSDL Listing 
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The current version of the design system does not 
support the use of CSDL for problem specifications, requiring 
that the user generate the list of primitives manually. A 
user specification format based on the Ada programming 
language is currently under development. [Ref. 8] In the 
interim, CSDL serves as a useful tool in understanding the 
structure of the problem specification required by the 
design system and the transformation it undergoes in the 
course of generating a design. 

B. INTERMEDIATE FORM OF THE PROBLEM 

The input specification is translated into an inter- 
mediate representation consisting of a list of primitives. 
This transformation is analogous to the operation performed 
by a compiler on high level languages such as Fortran and 
Pascal. The list of primitives is a complete description of 
the problem, containing all of the information necessary to 
generate a hardware and software implementation of the design 
problem and to verify that all timing requirements have been 
satisfied with the selected realization volume „ 

A second file, called the IADEFL file, is generated at 
the same time as the primitive list, and contains the list 
of contingency/task pairs and their corresponding timing 
constraints. This data is extracted from the ID table, the 
environment table, the timing data from the contingency 
list, and the design criteria table. The design criteria 
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table is generated from the data listed in the design 
criteria section of the CSDL listing. This section was 
added by Ross to provide a method for the designer to specify 
the criteria upon which an acceptable realization could be 
chosen. The criteria are: first realization generated, 

least costly realization, and the realization that uses the 
least power. The current version of the system only supports 
the first realization generated criterion. The creation of 
the IADEFL file and the primitive list is the first action 
taken by the design system in its attempt to generate a 
hardware realization. The operation of the design system in 
relation to these files is depicted in Figure 4. 

C. FUNCTIONAL ELEMENTS 

The problem formulation is performed by the user for 
both the high level description and intermediate represen- 
tation. Each of these tasks will eventually be automated 
as well, providing a user friendly interface to the design 
system. As stated previously, development of the input 
module is in progress, but until a satisfactory input 
specification to intermediate form translator can be 
developed, the input to the design system must be manually 
compiled . 

1 . Optimizer Module 

After the input files have been produced, they are 
passed to the first component in the design system, the 
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Figure 4. Flowchart of Automated Design System 



optimizer module. It serves two purposes, acting as the main 
program controlling the operation of the system, and func- 
tioning as the input module for the primitive list. Although 
not implemented in the current version of the system, this 
module will have the capability of comparing the multiple 
realizations generated by the system and selecting that one 
which best satisfies the chosen metric as specified by the 
user in the design criteria section of the input listing. 

2 . Functional Mapper 

The Functional Mapper is the first module called by 
the Optimizer, and is used to ensure that each primitive 
contained in the intermediate problem specification can be 
realized with the current realization library. This is 
accomplished using two separate operations. The realization 
volume index is first searched for the primitive name as 
given by the current line of the intermediate list. If the 
primitive is found, the specifications associated with the 
primitive are compared to those contained in the realization 
library. The mapping is considered successful only if all of 
the primitives can be realized and their criteria satisfied. 

If a given primitive cannot be mapped to a realization, or 
if its selection criteria fail to fit those of the realization, 
a new realization library will be searched. Failure to 
satisfactorily realize a primitive in any library results in 
an unsuccessful mapping. 
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3 . Timing Analyzer 

The second module executed is the Timing Analyzer. 

It generates the monitor necessary for controlling the 
operation of the device under development, ordering the 
execution of the realization contingency tests and task 
executions such that the timing constraints will be satisfied. 
In order to make such an assurance, the timing analyzer 
assumes that all contingencies are true. This requires that 
all of the tasks must be executed by the monitor and there- 
fore defines the worst case situation. The resulting premise 
is that if the worst case can satisfy the timing requirements, 
all cases satisfy them as well. The timing analyzer determines 
the length of time required to execute all of the code con- 
tained in each of the contingency/task pairs and compares it 
to the timing constraints listed in the Applications Timing 
Table as generated from the IADEFL file. If all of the 
timing constraints are met, the realization is successful. 

If not, the realization fails. The output of the Timing 
Analyzer is used to generate monitor primitives for success- 
ful realizations . These primitives determine the sequence of 
execution for the contingency/ task pairs, and are added to 
the list of primitives derived from the high level description 
of the problem. 

An important result of the research conducted by Ross 
was that the design system is capable of automatically 
producing multi-processor realizations. This is done in the 
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Timing Analyzer. If a single processor realization is 
impossible, the Timing Analyzer partitions the Applications 
Timing Table into two separate lists. Each of these contains 
the timing information corresponding to complete sets of 
contingency /task pairs. In other words, the partitioning of 
the problem results in groupings of these pairs. The 
regularly ordered nature of the contingency /task model makes 
this possible. In order to generate separate sets of hard- 
ware, the two timing tables are passed to the Formatter 
module individually. Theoretically, it is possible to pro- 
duce a realization in which each contingency/task pair is 
located in its own processor. It is important to note that 
such a system may require shared resources. The current 
version of the design system will only test for a dual 
processor realization when a single one fails. The 
generation of such a realization cannot be forced. 

4 . Formatter Module 

The Formatter receives the complete list of 
primitives necessary to produce the output listing for the 
design. The listing consists of the software necessary to 
perform the desired function and the hardware required to 
support it. The hardware and software listings are written 
to separate files which are in turn copied to an output 
device such as a terminal or line printer. The design 
program is then terminated. 
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D. REALIZATION LIBRARY 

The realization library has thus far been mentioned only 
in describing the operation of the other components of the 
design system, but its importance in the determination of a 
successful design should not be overlooked. Each realization 
library contains volumes of hardware and software primitives 
based on individual processor families. The only volume 
currently implemented uses the Intel 8080 microprocessor and 
its various support devices to generate realizations. 

The general format of each line in a volume is the same. 
Each line is assigned a unique identifying number, and 
contains a maximum of eighty characters. The first set of 
lines within the volume serve as an index to the primitives 
it contains. The lines of the index are copies of the title 
line of each entry. The current format of the realization 
volume allows a maximum of 9999 lines. The index is not 
considered when determining the number of lines contained in 
the volume . 

Each line of the volume must conform to a specific 
format, of which there are ten: Primitive Title line, 

Comment line, Calc line, Attr line. Call line, Include line. 
If line, Begin Text line, End Text line, and Text line. The 
title line begins with an S or H, to denote hardware or 
software, and contains the name of the primitive. As used in 
the current version of the design system, it is the most 
important of the lines found in the volume, providing the 
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correct format for generating each of the entries contained 
in the intermediate problem description. The calling 
arguments, selection criteria, and attributes of the 
primitive are enclosed in parentheses following its name. 

The attributes, which vary depending on the nature of the 
primitive, define such parameters as power consumption, 
latency, and chips used. Any or all of the arguments, 
selection criteria, and attributes may be omitted, but the 
commas that separate them must appear. The comment line is 
denoted by the appearance of the letters C-O-M as the first 
characters on the line . The text that follows is ignored by 
the system. The Calc line allows the use of global variables 
within the system. An example of its application is the 
counter variable used to total the number of chips used in a 
particular design. In the current realization library, this 
variable is called ICN and is incremented by any of the 
hardware primitives that contain integrated circuits. The 
Attr line is similar to the Calc line, but is used to 
compute the value of an attribute of the primitive realiza- 
tion. Incl and Call lines are used to invoke other primitives 
from within a primitive. The difference between the two is in 
the placement of the output that each generates. The output 
from a Call is inserted immediately following any previously 
generated output. Output from an Incl statement will be added 
to that of the primitive lists after all other output from 
the including primitive has been produced. The If line 
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provides more flexibility in library construction by 
allowing branch instructions within the realization volume. 
The Begin and End Text lines are used to reproduce descrip- 
tive lines in the files generated for system output by the 
Formatter module. These lines are in the final category of 
text lines. The most common use of text lines is for 
assembly code associated with a software primitive. Figure 
5 is an example of a short realization volume. The 
construction of the volume is further demonstrated and 
clarified in the text of the analog to digital converter 
realization developed in chapter four. 
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V2222S. SAMPLE 
V2223C0M THIS 
V2224C0M 
V2225C0M 
V2226C0M 
V2227C0M 
V2228C0M 
V2229C0M 
V2230COM 
V22 3 1 COM 
V2232COM 
V223 3COM 
V2234COM 
V223SC0M 
V2236C0M 
V2237COM 
V2238COM 
V2239ATTR 
V2240CALC 
V2241INCL 
V2242C ALL 
V2243C0M 
V2244C0M 
V2245COM 
V2246C0M 
V2247COM 
V2248C0M 

V2249IF DUMMY1 .GE. 2 SKIP 2 
V2250INCL H.SAMPFOUR C ) 

V225 1 COM INCLUDE H.SAMPFOUR ONLY IF 
V2252COM BEGIN THE TEXT BLOCK AFTER 
V2253BEGIN STEXT 

V2254 EVERYTHING IN THIS BLOCK BETWEEN BEGIN AND END 
V2255 COPIED TO THE OUTPUT LISTING EXCEPT FOR DUMMY 

V2256 ARGUMENTS AND GL08ALS WHICH ARE REPLACED BY THEIR 

V2257 ACTUAL ARGUMENTS OR VALUES. 

V2258ENDTEXT 



(PI, P2:0, 8, 0,5:10, 10,-17, 1 8 , 1 9 , 2222 , 2258 ) 

IS A COMMENT DESCRIBING S. SAMPLE. PI AND 
P2 ARE THE DUMMY ARGUMENTS OF S. SAMPLE. 0 AND 8 
ARE THE MINIMUM AND MAXIMUM VALUES OF THE ACTUAL 
ARGUMENT REPRESENTED BY PI, 0 AND 5 ARE THE 
CORRESPONDING MINIMUM AND MAXIMUM FOR THE ACTUAL 
ARGUMENT REPRESENTED 8 Y P2. THE 10,10 INDICATES 
THAT THE STORAGE AND TIME ATTRIBUTES FOR THIS ENTRY 
ARE EACH OF VALUE 10. THE -17 INDICATES THAT THE 
VALUE OF THE EXTERNAL ATTRIBUTE IS CALCULATED ON 
LINE 2239 ( 2222- ( - 1 7 ) =2239 ) . THE 18 INDICATES THAT 
LINE 2240 (2222+18=2240) CALLS FOR CALCULATION OF 
SOME GLOBAL VALUE. THE 19 INDICATES THAT LINE 2241 
CALLS FOR THE INCLUSION OF SOME OTHER REALIZATION. 
2222 AND 2258 ARE THE FIRST AND LAST LINE NUMBERS 
OF THIS REALIZATION. 

EXTERNAL = DUMMY 1 * 7 
TOTEVT = TOTEVT+1 
H.ALSOSAMPLE(0,0) 

S.SAMPTHREE (TOTEVT) 

H.ALSOSAMPLE AND S.SAMPTHREE ARE TWO OTHER ENTRIES. 
ALSOSAMPLE HAS TWO DUMMY ARGUMENTS, BOTH ASSIGNED 
VALUE ZERO IN THIS CASE. S.SAMPTHREE HAS ONE DUMMY, 
SET EQUAL TO THE GLOBAL TOTEVT FOR THIS CASE. 



DUMMY! IS LESS 
THE NEXT LINE. 



THAN TWO 



IS 



Figure 5. Sample Realization Library Entry 
[Ref. 8] 
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III. FILTERING METHODS 



With the advent of the microprocessor, a new and 
interesting device for the implementation of digital filters 
has been created. Increases in word length and computational 
speed will encourage more complex filtering applications 
using this device. It is therefore important to investigate 
the feasibility of producing digital filter realizations 
using the automated design system. The fundamental require- 
ments that the application places on the system can be 
determined using the Intel 8080 microprocessor library 
currently available. Despite the filtering limitations 
presented by its eight bit format, the deficiencies present 
in the current system can be identified and corrected. The 
resulting improvements will provide a more useful design 
tool and make possible the generation of satisfactory 
solutions to more demanding problems when additional 
realization volumes constructed around advanced 
microprocessors are added to the library. 



A. TRANSFER FUNCTION 

The general form of the digital filter transfer function 
is 



H ( z ) = 



-1 , -2 , , -n 

a n + a_,z +a„z + . . . + a z 
U I 2 n 



1 + b, z' 1 + b 0 z" 2 + . . . + b z 

12 n 
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where and are real coefficients and n is the maximum of 
the orders of the numerator and denominator polynomials . 

Figure 6 is a flow diagram representation of this transfer 
function. There are a number of similar structures that can 
be used to describe the basic filtering operation. Those in 
which the real coefficients a^ and b^ are multipliers are 
referred to as direct structures. Nagle and Nelson [Ref. 10] 
describe four direct structures and the equations associated 
with them. 

1 . First Direct Structure 

The first direct structure is derived from the 

equation 

n n 

HCz) = ( z a. z -1 )/( Z b. z" 1 ). 
i = 0 1 i=0 1 

The coefficient b Q is equal to one. Defining the input to the 
filter as X(z) and the output as Y(z), the previous equation 
can be rewritten as 



Y(z) 

xTz7 



ii .ii 

( Z a. z _1 )/( Z b. z -1 ). 

i= 0 1 i= 0 1 



This can be redefined using an intermediate variable M(z), 
such that 



Y(z) M(z) 
MTzT * XTz7 



11 >11 

( Z a. z -1 )/ Z b. z -1 ). 

i= 0 1 i= 0 1 
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Figure 6. Flow Diagram, Nth Order Transfer Function 




The following relationships can now be derived: 



Y( z) 
FTCzT 



( E a. z 
i= 0 1 



and 



M( z ) _ 1 

XTzT ~ n 

E b . z 
i=0 1 



or 



X( z ) 
MTzT 



n 



( E b. 
i= 0 1 




) . 



Rearranging these equations provides expressions for the 
input X(z) and the output Y(z) in terms of M(z): 



Y(z) = 



n 
( E 
i= 0 



z -1 )M( z ) 



and 



X(z) = 



n 
( E 
i = 0 



b . 
i 



z 1 )M( z) 
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Because the input is a known quantity, it is desirable to 
derive an equation for M(z) in terms of X(z). Manipulation 
of the previous equation for X(z) gives 

n 

M(z) = X(z) -Zb. z _1 M(z) 
i=l 1 

Because the calculations necessary to produce the filtering 
function are to be performed in real time, the inverse 
z-transform of M(z) and Y(z) is taken to provide a time 
domain solution of the first direct structure. The results 
are : 

n 

m(k) = x(k) -Zb. m(k-i) 

i = l 1 



and 



n 

y(k) = Z a. m(k-i) . 
i = 0 1 

The flow diagram of the first direct structure, of order 
two, is shown in Figure 7. 

2 . Second Direct Structure 

The transpose of a digital filter structure is 
formed by reversing the signal flow in all of the branches 
of the block diagram. Its transfer function is the same as 
that of the structure from which it was derived. The second 



35 




36 



direct structure is generated by applying this principle to 
the first direct structure. The corresponding time domain 
solution also implements the same filtering function, but an 
additional difference equation is required. The equations 
for the second direct structure are: 

p^(k) = p_^ + ^(k-l) + a_^x(k) - b^(yCk)); i = l,...,n-l 

p (k) = a x(k) - b y(k) 
n n- 7 

y ( k ) = a Q x(k) + p^(k-l). 

The second direct structure, of order two, is illustrated in 
the flow diagram of Figure 8. 

3 . Third Direct Srructure 

To obtain the third direct structure, the expression 

*7 / \ n. . n * 

H ( z ) = = ( E a. z _1 )/( E b. z -1 ) 

X'zT i=0 1 i = 0 1 

is rewritten as 

n n 

Y(z)( Z b. z -1 ) = X(z)( Z a. z -1 ). 

i = 0 1 i= 0 1 

The output expression is then 

n n 

Y(z) = E a. z _1 X(z) E b. z _1 Y(z). 

. _ n 1 • 1 

1=0 1=1 
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Figure 8. Flow Diagram, Second Direct Structure 



Once again taking the inverse z-transform, the time domain 
solution is derived: 

n n 

y(n) = E a. x(n-i) E b. y(n-i). 
i= 0 1 i = l 1 

Figure 9 illustrates the flow diagram for the third direct 
structure of order two. 

4 . Fourth Direct Structure 

The fourth direct structure is derived by taking the 
transpose of the third direct structure. The time domain 
representation is: 

r^Ck) = x(k) + r^(k-l) 

q l (k) = a n r 0 (k) 

r (k) = -b r n (k) 
n n 0 

q^(k) = a^r^Ck) + q_^ + ^(k-l), i=l,...,n-l 

r.(k) = -b.r n (k) + r.,,(k-l). 
i i 0 i+l 

The flow diagram for the fourth direct structure, of order 
two, is shown in Figure 10. 

B. SECOND ORDER SECTIONS 

Each of the structures described applies to the general 
case in which the filter transfer function is of order n. 

The filtering function can be successfully realized using 
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x(n) 
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Figure 9. Flow Diagram, Third Direct Structure 
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igure 1U. Flow Diagram, Fourth Direct Structure 



any of these methods, provided that n does not exceed two. 

For transfer functions of higher order, coefficient 
sensitivity becomes a significant factor in accurately 
generating the filter output. This phenomenon is created by 
the effects of quantization errors in the representation of 
the transfer function coefficients. The filter structures 
and their related difference equations assume finite 
precision in the filter parameters. However, because the 
word length used by microprocessors is fixed, the precision 
with which the filters can be realized is limited. This 
means that the coefficient representations are not exact, 
resulting in a set of poles and zeros for the realization 
that differ from those desired. The frequency response of 
the actual filter will therefore be different from the 
design specification. In the most extreme case, the filter 
will become unstable if one or more of the poles are moved 
outside of the unit circle [Ref. 11]. As shown by Rader and 
Gold [Ref. 12], high order filters can be redefined as 
combinations of first and second order sections in order to 
minimize these effects. 

C. COMBINATIONAL STRUCTURES 
1 . Cascade Structure 

The first combinational structure to be considered 
is the cascade form of the digital filter. It is illustrated 
in Figure 11(a) and is obtained by factoring the transfer 
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